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This memo proposes guidelines to use when designing the interface between an OIS 
processor executing the Mesa instruction set, hereafter called the emulater, and a peripheral 
device controller, hereafter called the controller. I^his memo also outlines the style of Pilot 
i/o transactions. 



The Controller Status Block 

The processor architecture allows as many as sixteen controllers attached to a single system 
element. The architecture assigns each controller a block of sixteen registers in the i/o page, 
virtual memory page zero. This register block, the conlrolier status block, provides status 
information for the emulator. The controller in turn periodically polls the CSB for 
commands from the emulator. For some peripherals, polling the CSB is an inappropriate 
method to initiate action. In that case, the emulator can use the OUTPUT instruction to 
initiate action directly. The emulator reserves the first CSB, virtual memory locations 0-15, 
for the processor and integrated controllers and the last CSB, locations 240-255, for 
handling faults. 



lOPage: array [0..15] or ControlierStatusBlock; 

lOCBHandle: carhinai/, 

ControlierStatusBlock: tyff. = macuink i)r,n:Ni)F,Nr j<r(ORi)[ 
chain: lOCBHandle, 
v/akeUpMask: cardinal;" 
devlceDependent: array [0..13] ok uNspKciriLi)]; -- CSB is 16 words 

The first word of the CSB points to a chain of input/output control blocks, lOCB's, The 
current plans are for Pilot to allocate all lOCB's from the first 64k of virtual memory. 
Using 16 instead of 24 bit pointers reduces the si/.e of lOCB's and alleviates timing 
problems since a double word store is unnecessary to v/rite lOCB pointers. It v/ould seem 
reasonable to maintain other Pilot data structures (e.g. ECB's and channels) in the first 64k 
of virtual memory for the same reasons. As the controller chases dov/n the chain, it updates 
the first word of the CSB to indicate the currently active lOCB. When the controller finds a 
zero, it stops processing and stores the zero into the CSB. 

The second word of the CSB contains the wake up request bit mask. The controller looks 
here to determine which process or processes to wake up when events require. 
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The other 14 words of the CSB are unassigneci and can be used for device dependent status 
and commands. 



Input/Output Control Blocks 

lOCB's hold information passed between the emulator to control input and output 
transactions. The en>u)ator places a command and buffer descriptor in the lOCB and puts 
the iOCB on the chain. After the controller processes the lOCB, it stores a completion code, 
and, depending upon the command code, generates process wake ups. 

IOCB: T\i'r<: = mac hinf: DrPKNOF-NX rfcordI] 
next: lOCBHandle, 
buffer: long pointfr to uNsrr.cMFj), 
command: lOCBCommandCode, 
complelion: lOCBCompletionCode, 
byteCount: cardinal, 
maxByteCount: cARorNAi., 
synch: EventlD, 
previous: lOCBHandle, 
deviceDependent: array of uNs^FxirrFD]; 

The first word of an IOCB points to the next fOCB on the chain. A zero indicates the end 
of the chain. 

The next two words are a 24 bit pointer to the buffer. 

The emulator writes a command code into the fourth word. Three bits of this word are 
reserved to control process wake ups. 

lOCBCommandCode: tvff = r>L\<:H{NF dfpendfnt rfc:oro[ 
Vv^akeUpAlways, -- bit 

vvakelipOnError, -~ bit 1 

stopOnFirror: booffan, -- bit 2 Don't process next IOCB on error 
deviceDependent: [0..1 7777B]]; 

The controller wakes up the processes indicated by the wake up request bit mask in the CSB, 

The controller v/rites a completion code in fifth word. Two bits of this word are reserved. 

lOCBCompletionCode: iypf = machfnf ufpfnofnt rf(or()[ 
processed: -- bit 

enor: -- bit 1 

deviceDependent: C0..37777B]]; 

The rest of the word contains a device dependent code. The emulator can determine 
whether the controller has processed the 10Cf> by vvritins zero in this word before placing 
the IOCB on the chain. The controller guarantees to write a non-":<ero quantity after 
processing. 
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The sixth word of the lOCB holds a count of valid data bytes in the buffer. If the 
controller fills the buffer, then this word holds the number of bytes written after processing 
the lOCB. If the controller empties the buffer, this word contains the number of bytes to 
transfer. 

The emulator uses the seventh word of the lOCB to write the maximum length of the 
buffer. If the controller fills the buffer, the number of bytes v/ritten must not exceed the 
maximum length. If the controller empties the buffer, this word is redundant with the byte 
count. 

The eighth word holds a Pilot event ID. On completion of processing the lOCB, the 
controller posts the event. This has the same effect as a Mesa call to post the event, but this 
method obviates a process switch. 

The ninth word contains a pointer to the previous lOCB in the chain. This word facilitates 
insertion of lOCB's in the middle of the chain. Not all devices require such flexible 
control! over the lOCB; in that case, this field is omitted. 

Tire last part of the lOCB can be used to hold device dependent status and control. For 
example, the floppy disk uses this area to hold the disk block header and label. 
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